The desire for high-volume, real-time transaction processing environments is well-known, for organizations such, as, stock brokerages, credit card processing facilities and online reservation systems. For example, from an operational point of view, “transactions” may include sales orders, credit card transactions or accounting journal entries. From a software point of view, transactions may include, for example, database transactions of the sort that keep information in a consistent form.
High-performance transaction processing used to be a rare phenomenon, utilized only in extreme environments by the largest companies. But in recent years, the Internet has opened the door to the arrival of global customers in quantity through e-commerce sites, call centers, and other forms of direct interaction. Business-to-business relationships are intermediated by direct computer-to-computer interaction, frequently based on Web services. Content delivery and mediation for services must take place in real-time. This bulge in transaction traffic follows the same pattern that has transformed the telecommunications industry from a few providers of old-style, fixed local and long distance calling services into a competitive field of real-time enterprises offering wireless mobile plans for delivery of complex, combined data, voice and video content.
The requirements of global and real-time transaction processing are becoming the norm, driving enterprises to seek out IT systems whose architectures can handle skyrocketing transaction volumes at the lowest possible cost per transaction, in a manner that allows for flexibility and agility in service offerings. Flexibility, high performance and low cost constitute a new transaction-processing triangle that confounds solutions and architectures designed on proprietary systems as recently as a decade ago.
One approach (which, while described here in the “Background,” is not admitted to be prior art to the subject matter claimed herein) is a transaction processing development methodology employs a flexible transaction processing development framework to facilitate development of a desired transaction processing application. See, for example, U.S. patent application Ser. No. 11/959,333, filed on Dec. 18, 2007 and U.S. patent application Ser. No. 11/959,345, filed on Dec. 18, 2007. Both application Ser. No. 11/959,333 and application Ser. No. 11/959,345 are incorporated herein by reference in their entirety for all purposes.
In these patent applications, an example of a transaction processing development framework is described. In the described example, a plurality of service adaptors are provided. An infrastructure is provided via which a user-defined business logic of the desired transaction processing application may be provided to the transaction processing development framework. The business logic definition is processed to instantiate the transaction processing application, including, instantiating a subset of the service adaptors to implement services of the transaction processing application, and further including arranging the instantiated service adaptors to accomplish the business logic in conjunction with generic transaction processing logic. The arrangement of service adaptors is guaranteed, when executed, to accomplish the transaction processing application in a manner that is fully transactional.
Furthermore, other prior patent applications (U.S. patent application Ser. No. 12/433,087, filed on Apr. 30, 2009 as; U.S. patent application Ser. No. 12/433,094, filed on Apr. 30, 2009 as; U.S. patent application Ser. No. 12/433,617, filed on Apr. 30, 2009 as; and U.S. patent application Ser. No. 12/433,742, filed on Apr. 30, 2009 as, all of which are incorporated herein by reference in their entirety for all purposes) describe a computing system in which the specification of a user-defined business logic may be provided as JAVA program instructions (or another programming language) which does not natively provide for specification of full transactionality, and the computing system ensures that a resulting configured system is fully transactional. Furthermore, the resulting configured system may include fully transactional managed objects that may, for example, be persisted in a global shared memory.